
\chapter{Étude de l'existant}

En matière de logiciels de tests, l'état de l'art n'en est pas à son stade le plus primaire. En effet, nous pouvons noter qu'il existe quantité de programmes, voir de FrameWork, pourvus de fonctionnalités similaires à SPASS.
Les premiers programmes nous venant à l'esprit sont ceux qui vivent au sein d'un terminal.

\section{Logiciels d'analyse, de test et de performance}

\subsection{Valgrind}
\textbf{Valgrind} (libre) est un logiciel dit de \emph{profiling}. Il évalue l'utilisation de la mémoire d'un autre programme écrit en C ou en C++, pour permettre, par exemple, de détecter d'éventuelles fuites mémoires. \textbf{Valgrind} est écrit de façon modulaire, chacun de ses modules ayant une tâche particulière, avec notamment :
\begin{itemize}
\item Débusquer les failles d'un programme au niveau de l'utilisation de la mémoire.
\item Analyser l'utilisation des caches du/des processeur(s) afin de détecter un possible ralentissement du programme.
\item Analyser l'utilisation de la pile pour déterminer des portions de programme inutilisées.
\end{itemize}
Valgrind nous servira de profileur pour les programmes à tester écrits en C/C++.

\subsection{Commande UNIX \emph{time}}
La commande \textbf{time} permet de chronométrer le temps d'exécution d'une programme ou d'une commande, et de rendre le résultat selon trois valeurs :
\begin{itemize}
\item Le temps utilisateur : temps passé par le processeur à exécuter du code en mode \emph{utilisateur}.
\item Le temps noyau : temps passé par le processeur à exécuter du code en mode \emph{noyau}.
\item Le temps réel étant la somme des deux temps ci-dessus.
\end{itemize}
La commande time, simple d'utilisation, nous servira pour calculer le temps d'exécution des programmes en test.

\subsection{Strobe}
\textbf{Strobe} (payant) est une des solutions proposés par Compuware (\href{http://www.compuware.com}{\nolinkurl{http://www.compuware.com}}). \textbf{Strobe} mesure les performances des applications à la fois en ligne et les applications de traitement par lots, et tente d'identifier les défaillances chroniques et récurrentes qui monopolisent le processeur. \textbf{Strobe} étant un logiciel propriétaire payant, nous ne pourront pas l'utiliser (ni s'en inspirer), dans notre projet.

\subsection{McCabe IQ}
\textbf{McCabe IQ} (payant) s'intéresse à l'analyse du code ou de l'architecture du logiciel soumis aux tests. Il est compatible avec un nombre important de langages et évalue la qualité et les problèmes relatifs à l'architecture. Il est entre autre capable d'effectuer des analyses statiques avancées dans les parties les plus complexes du code, dans le but d'identifier les bogues et failles de sécurité. Pour la même raison que \textbf{Strobe}, nous ne pourrons pas utiliser \textbf{McCabe} dans notre projet.

\subsection{Sonar}
\textbf{Sonar} (libre sous \emph{GNU General Public Licence v3} et open source) est pour sa part spécifique à Java. Ses tests portent sur la duplication de code, la complexité, le respect du niveau de documentation et des règles de programmation, etc... Il est à remarquer qu'un plugin (metricC++) permet de rendre \textbf{Sonar} compatible avec C++. 

\subsection{SourceMonitor}
\textbf{SourceMonitor} (libre, \href{http://www.campwoodsw.com/sourcemonitor.html}{\nolinkurl{http://www.campwoodsw.com/sourcemonitor.html}}) repose principalement sur les métriques de fonctions et peut s'appliquer à un grand nombre de langages. Il permet de voir l'intérieur du code source du logiciel pour identifier la complexité relative des modules et identifier le code qui est le plus susceptible de contenir des défauts. \textbf{SourceMonitor} est écrit en C++.

\subsection{FrameWork de types xUnit}
Les FrameWorks de types xUnit\cite{Un04} permettent d'effectuer des tests unitaires dans la plupart des langages, comme \emph{JUnit} (langage Java), \emph{PyUnit} (langage Python), \emph{CUnit} (langage C) etc... Dans notre projet, l'utilisation de PyUnit nous permettra d'effectuer des tests unitaires sur les programmes soumis.

\subsection{Ideone}
\textbf{Ideone} (\href{http://ideone.com}{\nolinkurl{http://ideone.com}}) permet de tester un code source sur un nombre non négligeable de langages de programmation (plus de 40, y compris les plus improbables comme le langage \emph{Brainf**k}
\footnote{Brainfuck est un langage de programmation minimaliste, inventé par Urban Müller en 1993, similaire à une machine de Turing}). Le test se résume à compiler le programme, exécuter ce dernier et afficher sa sortie. Un résumé sur le temps mis pour la compilation et l'exécution est disponible. Sa particularité réside dans le fait que c'est une \emph{Web Application}
\footnote{Application qui est accessible via un navigateur Web sur un réseau comme Internet ou un intranet}. Du fait de son utilisation via navigateur Web, son utilisation ne pourra pas être effective dans notre projet, mais nous pourrons nous inspirer de certains aspects, notamment au niveau de la sécurité pour la compilation/exécution sur environnement distant.

\section{BOSS : un sytème similaire}

Le système \textbf{BOSS}\cite{Jeric} (\href{http://www.dcs.warwick.ac.uk/boss}{\nolinkurl{http://www.dcs.warwick.ac.uk/boss}}) est très proche de notre sujet. Il permet de récupérer les projets des étudiants, vérifie leurs intégrités, effectue des séries de Test BlackBox (JUnit) et WhiteBox, et détecte si le code a été plagié. Les tests WhiteBox apprécient principalement la qualité du code. C'est à dire la présence de commentaires, le style de programmation, la structure interne, l'efficacité, etc... Pour les tests BlackBox, le système se base sur deux paradigmes :
\begin{itemize}
\item Le premier repose sur des tests effectués sur la sortie du programme.
\item Le second repose sur les tests unitaires et plus particulièrement sur le FrameWork JUnit.
\end{itemize}
Nous pourrons nous inspirer de BOSS sur plusieurs aspects (environnement d'exécution sécurisé, manière dont les tests sont effectués, interface graphique Web, etc...).

\section{FrameWork Web Python}
SPASS étant pourvu d'une interface Web, nous devons choisir parmi une longue liste, quel FrameWork utiliser pour implémenter cette interface. Notre projet étant écrit en Python, nous choisissons naturellement un FrameWork Web également écrit en Python. Voici une liste (non exhaustive) de FrameWork Python qui existent.

\subsection{Pylons}
Pylons combine à la fois des idées tirées de Ruby, Python et Perl, fournissant un Web FrameWork Python tout autant structuré que flexible. C'est un des premiers projets à utiliser les standards WSGI, qui autorisent ré-utilisation et grande flexibilité. Pylons est construit sur \emph{Paste}
\footnote{Ensemble d'utilitaires pour le développement Web en Python}. Pylons cumule maintenant un peu plus de 4 ans de développement. Pylons était initialement le FrameWork retenu pour la construction de SPASS. Seulement son support/développement semble s'être considérablement ralenti ces derniers temps...

\subsection{Django}
Django est un FrameWork Web Python de haut-niveau permettant un développement rapide. Django se concentre au maximum sur l'automatisation, en respectant les principes du \emph{DRY}
\footnote{\emph{Don't Repeat Yourself}, typiquement la non-duplication de code}.
Django permet de construire des applications Web haute performance et simple en peu de temps. La documentation en ligne de Django est très complète. Un des défaut de Django, est la non-intégration de l'AJAX coté client Web de manière native. Il faut utiliser des librairies externes pour l'utilisation de l'AJAX avec Django. Enfin, Django cumule, tout comme Pylons, un peu plus de 4 ans de développement.

\subsection{TurboGears}
TurboGears combine à la fois CherryPy, Kid, SQL Alchemy et MochKit. TurboGears est aussi construit sur Pylons pour la partie \emph{controler}
\footnote{Intergiciel qui permet aux applications Web d'être programmées par des gestionnaires d'événements}. Un des inconvénients de TurboGears est que chaque composant utilisé n'est pas modifiable (comme SQL Alchemy par exemple). Cela pourrait poser problème en cas de future ré-utilisation de SPASS sur un environnement qui nécessite un autre type de FrameWork SQL. L'utilisation de TurboGears comme FrameWork Web est donc définitivement écartée de notre projet.
\subsection{Zope}
Zope est un FrameWork Web orienté objet. Zope gère des objets Python qui sont enregistrés dans une base de données orientée objet, ZODB. Zope serait l'ancêtre des autres FrameWork (développé depuis 1998), mais dispose de peu de fonctionnalités annexes, il sert essentiellement de serveur. L'utilisation d'objets et leur stockage dans une base de données orientée objet, permettant de coder une page Web avec une architecture objet similaire à celle d'une application, ne nous est à première vue pas familière, et nous redoutons par la suite des blocages dû à cette implémentation particulière. Nous préférons donc rester dans un FrameWork Web plus conventionnel, pour éloigner tout problème susceptible d'apparaître par la suite.

\section{FrameWork SQL}
Afin de mieux comparer les différents Web FrameWork, il convient de regarder comment chacun d'entre eux interagit avec les bases de données, étant dit que le noyau de SPASS doit gérer des droits, les authentifications et des groupes de travail.
Cette section décrit les moyens utilisés par chaque Web FrameWork, ces moyens étant définis plus bas.\\

\begin{itemize}
\item Pylons intègre des solutions intéressantes et recouvrant plusieurs domaines. Certaines interactions via la base de données sont améliorées, grâce à l'utilisation de WSGI en lieu et place de CGI. La base de données en elle même est gérée par 2 moyens: SQLAlchemy et SQLObject. SQLAlchemy permet une intéraction avec énormément de bases de données et une recherche rapide alors que SQLObject est plus orienté vers une simplicité d'utilisation dans du code Python, le choix entre ces 2 solutions permet donc d'adapter le retour des bases de données aux préférences d'utilisation. Enfin, Django intègre une base de documents via CouchDB, qui pourrait voir des utilisations pour le stockages de documents relatifs aux travaux demandés par un enseignant ou autres documents qui auront a être mis à disposition sans avoir à être dans le dépot.
\item Django prend en compte plusieurs bases de données gérées nativement (PostGreSQL, MySQL, Oracle et SQLite) et d'autres dont la gestion est possible via des passerelles (Sybase SQL Anywhere,IBM DB2, Microsoft SQL Server 2005 et Firebird). Django est donc moins "modulaire" dans le sens ou on ne passe pas par une API pour la base de données, on doit donc choisir une base de données précise et adapter le code, et les requêtes, à la base de données utilisée.
\item TurboGear, fidèle à sa philosophie, ne propose qu'une seule possibilité: SQLAlchemy. Cette solution permet de s'interfacer avec de nombreuses bases de données mais sans fonctionnalités particulières. Une solution somme toute relativement "pauvre" car obligatoire et pas forcément conforme aux attentes, mais néanmoins plus modulaire que ce que propose Django.
\item Zope ne propose qu'une seule gestion de base de données: ODBC. Tout comme TurboGear, il est regrettable de n'avoir qu'une seule solution. ZODB, la base de donnée Objets pour programmation Web est gérée nativement mais ne présente pas à nos yeux d'intérêts.\\
\end{itemize}

\newpage

Les différentes solutions sont présentées ici:\\
\subsection{SQLALchemy}
SQLALchemy est une solution puissante car son API nous autorise à utiliser de nombreuses bases de données (PostgreSQL, SQLite pour du python 2.5 ou plus, MySQL, Oracle, Firebird, SQL Server, Sybase, MaxDB, MSAccess et Informix), tout en bénéficiant du data mapping. Cette technologie permet d'utiliser une base de données sans ce soucier de sa structure (objet, relationnelle, hiérarchique, réseau), assurant une facilité d'utilisation. SQLAlchemy est écrit en Python, nous évitant des problèmes de typages spécifiques à certains langages.

\subsection{SQLObject}
SQLObject supporte moins de bases de données que SQLALchemy (MySQL, PostgreSQL, SQLite, Firebird, MaxDB, Microsoft SQL Server), mais rajoute une couche d'abstraction très pratique pour la programmation en Python: les objets renvoyés par chaque requête sont très similaires à ceux utilisés en Python. Ils sont donc manipulables de la même manière que n'importe quel objet Python, simplifiant grandement leur utilisation au sein du code.

\subsection{ODBC}
ODBC est une solution développée en partie par Microsoft sans être propriétaire (malgré une idée reçue) permettant de s'interfacer avec diverses bases de données. Une base de données est compatible grâce à un driver qui lui est spécifique. Cette solution est devenue extrêmement puissante du fait que quasiment toutes les bases de données ont des drivers ODBC. Cette solution a aussi pour avantage d'être fortement normalisée (ANSI et ISO), assurant de bénéficier de nombreux outils. Elle est néanmoins fortement liée au C ou C++ car renvoi des pointeurs.